feat(cli): add app server to cli - #2034

补充：基于最新 head e6705251 的长期演进建议（供决策）

先确认本次更新：ConfigUpdate 的 TS 生成问题已补充修复，迁移 plan 也已从 docs/architecture 移到 docs/plans。以下只讨论长期路线，不替作者/维护者作最终决策，也不要求在本 PR 一次完成所有阶段。

1. 当前真正需要解决的问题

最新版的实际运行链路仍是：

flowchart LR
  TUI --> TB["TuiBackend<br/>当前直接使用 App Server DTO"]
  TB -->|Embedded| EA["AppServerTuiBackend"] --> IM["in-memory App Server"] --> ER["Embedded Runtime"]
  TB -->|Shared| SA["SharedTuiBackend<br/>协议翻译"] --> IPC["Runtime IPC v17<br/>Pipe / UDS"] --> SR["Shared Runtime"]

因此当前统一的是 TUI 源码侧接口和 DTO，尚未统一 Shared 的鉴权、controller/lease、事件恢复、断连取消和进程生命周期。SharedTuiBackend 仍需合成 App Server 的 initialize、capabilities 和 limits，也说明客户端内部端口与外部 wire contract 发生了耦合。

长期设计应把三个问题分开：

1. 客户端行为契约：TUI/GUI 需要哪些稳定用例、错误和事件。
2. 业务实现与 owner：Session、Turn、Permission、Workspace 等仍由既有 Runtime owner/ports 负责。
3. 部署与连接治理：Embedded、Shared、Web/Remote 各自需要不同的 transport、认证、controller 和生命周期。

统一第 1、2 层，不等于现在就必须统一第 3 层的 wire。

2. 几种长期方向对比

3. 推荐目标结构

flowchart TB
  TUI --> TB["TuiBackend<br/>TUI 内部稳定契约"]
  TB --> EA["Embedded adapter"]
  TB --> SA["Shared v17 adapter"]

  EA --> UC["窄的 Runtime use cases / owner ports"]
  SA --> V17["Private Pipe / UDS IPC"] --> HA["Shared Host authority<br/>identity · controller · event arbitration"]

  RC["Web / Desktop / external Rich Client"] --> ASC["App Server client / transport"] --> AR["App Server router"]
  AR --> HA
  HA --> UC

图中的 Runtime use cases 表示同一套实现与合同，不表示全局单例。建议优先复用现有 Runtime API、runtime-ports 和 owner handler，只抽取已经重复的复合用例，不新增大而全的第二个 Runtime service。剪贴板、外部编辑器、终端 raw mode 等 controller-local effect 继续留在 Client/Host。

TuiBackend 这个边界值得保留，但长期不应直接以 bitfun_app_server_protocol DTO、initialize/health 和 AppServerEvent 塑形；应改为 TUI-local 或稳定 domain DTO，由 Embedded、Shared v17、App Server adapter 分别映射。

4. 粗粒度分阶段建议

1. 阶段 0：先稳定边界

   • 保留 TuiBackend 概念，逐步解除它与 App Server wire DTO 的直接绑定。
   • Embedded 默认走同进程强类型 adapter；Shared 继续使用现有 v17 IPC。
   • 架构文档区分 Current、Proposed 和有证据门控的最终决策，不先承诺删除 v17。

2. 阶段 1：统一业务行为

   • 让 Embedded adapter、Shared handler 和 App Server router 复用同一组窄 Runtime use cases/owner ports。
   • 为 Session/Turn/Permission/取消/未知结果建立跨 adapter 行为合同测试，避免三套业务实现。

3. 阶段 2：让 App Server 在真实 Rich Client 中成熟

   • 以实际 Web/Desktop/外部 Client 的垂直切片推进，而不是先扩大全量 method。
   • 补齐版本与 capability、方向性 limits、身份与作用域、背压、事件 lag/resync、断连恢复、配置/环境来源和性能基准。

4. 阶段 3：Shared 双栈验证

   • 可在现有 Shared Host 中增加默认关闭的 App Server transport，保留 v17 作为可回滚路径。
   • 开放第二 transport 前，两条 transport 必须共享 Host-scoped connection authority、controller registry、Session 事件过滤、operation identity/deadline/cancel 和未知结果登记；否则可能出现双 controller 或策略绕过。
   • 先迁移一个第一方 Client 灰度验证，并覆盖跨 transport 竞争、断连、迟到结果和 Host 崩溃。

5. 阶段 4：按证据决定是否收敛 wire

   • 只有在鉴权、instance identity、controller/lease、事件恢复、背压、outcome_unknown、Windows Job/Named Pipe、Unix 清理以及启动/延迟/内存达到等价后，才决定是否让 Shared TUI 改走 App Server 并删除 v17。
   • 如果没有足够的多 Rich Client 收益，保留私有 Shared IPC 也是合理终态；业务实现仍然可以保持统一。

5. 是否值得以及主要代价

值得长期投入的是：稳定的客户端端口、共享的 Runtime 用例实现，以及面向真实 Rich Client 的 App Server 边界。当前不值得预先承诺的是：为了形式上的单一 wire，让默认 Embedded 和已成熟 Shared 同时承担协议迁移风险。

推荐方案的主要代价是阶段性维护 v17 与 App Server 两套协议、映射和故障测试；但这部分成本是有边界、可回滚的，换来的是不牺牲当前 Shared 的 controller、安全与恢复语义。是否最终删除 v17，应由真实消费方数量、维护成本和等价验证结果决定。

6. 同类产品的启示

• Codex TUI 已支持 Embedded、Local Daemon 和 Remote App Server target，说明 AppServer-first 在协议、Client 生命周期和恢复语义成熟后是可行路线，但不能证明 BitFun 可以跳过现有 Shared 语义的等价迁移。
• OpenCode TUI 采用 server/client 合同，但默认本地路径通过 Worker 和 in-process app.fetch 调用，只有显式网络参数才走网络。这说明“统一客户端语义”不必等同于“所有部署立即统一物理 wire”。

这些实现更能证明 App Server 路线的长期可行性，而不是证明当前阶段必须替换 BitFun 的 v17 Shared IPC。

7. 对最新版架构文档的建议

docs/plans 的目录调整已经符合预期。对于新增 app-server-architecture.md 中“Embedded Rich Client 必须经过 App Server”以及“Shared 最终删除旧 wire”的绝对表述，建议暂时改为 Proposed target + 明确决策门槛。如果作者最终仍选择方向 A，也建议把额外启动/资源成本、Shared 治理迁移范围和回滚条件作为显式取舍记录下来；最终方向由作者和维护者基于上述证据决定。